home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / newsgroups / misc.19980901-19981211 / 000340_news@newsmaster….columbia.edu _Tue Nov 24 11:18:43 1998.msg < prev    next >
Internet Message Format  |  2020-01-01  |  7KB
  1. Return-Path: <news@newsmaster.cc.columbia.edu>
  2. Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.35.30])
  3.     by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id LAA04280
  4.     for <kermit.misc@watsun.cc.columbia.edu>; Tue, 24 Nov 1998 11:18:42 -0500 (EST)
  5. Received: (from news@localhost)
  6.     by newsmaster.cc.columbia.edu (8.8.5/8.8.5) id LAA18078
  7.     for kermit.misc@watsun; Tue, 24 Nov 1998 11:18:42 -0500 (EST)
  8. Path: news.columbia.edu!watsun.cc.columbia.edu!fdc
  9. From: fdc@watsun.cc.columbia.edu (Frank da Cruz)
  10. Newsgroups: comp.protocols.kermit.misc,de.alt.comm.mgetty
  11. Subject: Re: At Wit's End on system freezes
  12. Date: 24 Nov 1998 16:18:40 GMT
  13. Organization: Columbia University
  14. Lines: 113
  15. Message-ID: <73em90$6ch$1@apakabar.cc.columbia.edu>
  16. References: <365ACCF8.1C502662@ouray.cudenver.edu>
  17. NNTP-Posting-Host: watsun.cc.columbia.edu
  18. Xref: news.columbia.edu comp.protocols.kermit.misc:9547 de.alt.comm.mgetty:8190
  19.  
  20. In article <365ACCF8.1C502662@ouray.cudenver.edu>,
  21. Joseph L. Kaiser <jlkaiser@ouray.cudenver.edu> wrote:
  22. : This is addressed to whoever can help.  I am at my wit's end.  I am the
  23. : systems administrator for a small medical transcription company in
  24. : Golden, Colorado.  We are running RedHat Linux 4.2 with the 2.23.30
  25. : kernel.  I have a set of four Zoom modems on a RocketPort 16 port PCI
  26. : board; the modems are used for both dialout (sending completed work to
  27. : clients) and dialin (receiving work from transcriptionists) and are on a
  28. : rollover line so they are accessed in sequence.  We are using "mgetty"
  29. : 1.1.15 for the getty processes on all of the modems and we use Kermit
  30. : 6.1 for all the dialout scripting and the dialin file transfer programs.
  31. : 
  32. : The problem is, in short, that my system periodically freezes and it
  33. : appears to be as a result of just Kermit or Kermit and mgetty.
  34. : 
  35. To isolate the problem, you must separate Kermit and mgetty.  My long
  36. experience has told me that bidirectional terminal ports on Unix rarely
  37. work as desired, and when problems such as this occur, they can almost
  38. always be attributed to the bidirectionality.  Remove that and the problems
  39. go away.
  40.  
  41. I know this is not a very satisfying answer, since modems and phone lines
  42. cost money, and so should be shared whenever possible.
  43.  
  44. : The history of the problem is this.  We upgraded to RedHat 4.2 and a new
  45. : ethernet network.  The modems were attached to the serial ports of the
  46. : nodes of the network (4) for various and sundry reasons.  The system
  47. : would freeze/crash so that I would have to reboot anywhere about every
  48. : 3-10 days.  We pulled the modems in July and put them all on the
  49. : Rocketport on the main server.   The system began to freeze about 1-5
  50. : times a day and I had to reboot that often.  I started to rule things
  51. : out.  I obtained the latest and greatest RocketPort driver.  The
  52. : behavior stayed the same.  I played with the initialization strings in
  53. : mgetty and the behavior stayed the same.
  54. :
  55. This is a critical area.  There might very well be a setting that makes
  56. the problem go away, but you didn't hit upon it in your experimentation.
  57. For example, did you try all possible DSR-behavior selections?  (&S0,
  58. &S1, &S2, ...)
  59.  
  60. : In the middle of all this, I
  61. : discovered that if I turned on and off the offending modem my system
  62. : "unfroze" without rebooting.  This saved a lot of time and frustration
  63. : for all concerned.
  64. :
  65. Because it resets the modem to its factory or saved state, which agrees
  66. with what mgetty and the port drivers need.
  67.  
  68. : I then sought to find out what made a modem an
  69. : offending modem.  It appears to boil down to Kermit file transfers.
  70. : 
  71. What else are you using the modems for besides Kermit transfers?
  72.  
  73. : We serve approximately 14 hospitals and we dial in to those hospitals
  74. : 3-4 time each every day.  The scripts for doing this are automated.
  75. : Frequently, a send will fail in some way, the login procedure won't go
  76. : to completion, a prompt will be missed,  or a file transfer will fail
  77. : repeatedly, all of these require that the script be started over.
  78. :
  79. Of course the script can be written to catch and recover from all these
  80. events.
  81.  
  82. : Sometimes when the script is restarted and the modem is then accessed
  83. : the system freezes, as if  the modem is already being used but no lock
  84. : file exists.
  85. :
  86. When you say "the system freezes", do you mean the entire system, or do you
  87. mean the process that is trying to open the modem?  If you mean the whole
  88. system, then there is a serious problem in the system itself, since no
  89. user program should be able to freeze Linux.
  90.  
  91. : Also, it may fail if a send has left the modem in an
  92. : unstable(?) state and someone connects to the modem rather than
  93. : quitting.
  94. :
  95. If the Kermit process exits in the normal way, it will close the modem, hang
  96. up the connection, release the lock, and restore the port driver to the
  97. settings it had when the port was opened.
  98.  
  99. If Kermit terminates abnormally, i.e. crashes, then you should report that 
  100. to us.  If it is terminated from outside abnormally -- killed from another
  101. process, or suspended and then killed -- normal UNIX process-exit rules
  102. apply, meaning, in most cases, that the port is simply closed.
  103.  
  104.   It is almost always the case that the system freezes when we
  105. : try to do something with a send that has stalled, i.e. when we try to
  106. : get a C-Kermit prompt with our escape character or we try to connect to
  107. : the modem.  (By stalled I mean it looks like it has accessed the modem
  108. : but it does not dial or initialize the modem.)  If a send has stalled
  109. : and I go to kill the process as root or the user kills the process, the
  110. : system also freezes.
  111. : 
  112. If Kermit is stuck in an i/o system call after successfully opening the modem,
  113. this is probably a consequence of the state in which a previous incoming call,
  114. or mgetty itself, has left the modem.  There's not much Kermit can do about
  115. this.  Before Kermit can set up the modem for originating a call, the driver
  116. has to allow i/o, but evidently this is not happening.
  117.  
  118. So again, my first recommendation would be to separate the inbound and
  119. outbound modems.  Configure the inbound modems for answering calls, and let
  120. Kermit handle the outbound modems.  Pay very careful attention to the modem
  121. signal configurations on the modems (&Sn, &Cn, &Dn, etc), which MUST agree
  122. in every respect with what your port drivers require.
  123.  
  124. Another idea would be to configure Kermit to:
  125.  
  126.   set modem hangup-method rs232
  127.  
  128. and make sure the modem is set to hang up the connection and return to command
  129. state when DTR drops (normally &D2), and use C-Kermit's "generic-high-speed"
  130. modem type, whose init string is simply AT&F (reset to factor defaults).
  131.  
  132. - Frank